1. Field of the Invention
This invention relates to a packet-based multimedia communications system and, more particularly, to a system having a fast connect option for enforcing symmetric codec capabilities in call setup procedures such as the fast connect setup in the International Telecommunication Union Standardization Sector (ITU-T) Recommendation H.323, incorporated herein by reference.
2. Description of the Prior Art
The International Telecommunications Union (ITU) H.323 standard describes terminal and other entities that provide multimedia communication services over Packet Switched Networks (PSN). H.323 devices provide real-time audio, video, and/or data communications. H.323 devices must support audio, while data and video are optional. If data or video is supported, the device must use a specified common mode of operation, so that all terminals supporting that media type can interface properly.
FIG. 1 is a functional block diagram of a packet-based multimedia communications system 10. The system 10 includes a PSN 12 connected to terminals 14, 16, and 18, gatekeeper 20, gateway 22, and multi-point control unit 24. Gateway 22 provides Voice Over Internet Protocol (VoIP) access between the PSN 12 and a Public Switched Telephone Network (PSTN) 26 and an Integrated Services Digital Network (ISDN) 28. PSTN 26 is connected to several PSTN endpoints, such as PSTN endpoints 30 and 32. PSTN endpoints 30 and 32 are standard circuit switched telephones. Phones 30 and 32 access one another through PSTN 26. Phones 30 and 32 access ISDN endpoints 34 and 36 through gateway 22. Similarly, ISDN 28 is connected to ISDN endpoints, such as ISDN endpoints 34 and 36. ISDN endpoints 34 and 36 are, for example, digital visual telephone terminals and equipment. ISDN endpoints 34 and 36 access one another through the ISDN 28 and access phones 30 and 32 through gateway 22.
VoIP services are accessed from the phones 30 and 32 via PSTN 26, more directly through the PSN 12 by digital phones 34 and 36 via ISDN 28, or from an H.323 endpoint to another through the PSN 12. In the first two cases, a phone connection involves dialing into an incoming gateway and connecting to a terminating gateway that eventually connects to a destination telephone.
The H.323 standard covers the technical requirements for multimedia communications systems where the underlying transport is a PSN 12. The PSN 12 may include Local Area Networks (LAN), Enterprise Area Networks, Metropolitan Area Networks, Intra-Networks, and Inter-Networks (including the Internet). The PSN 12 also includes dial up connections or point-to-point connections over the PSTN 26 or the ISDN 28 that use an underlying packet based transport such as a point-to-point protocol. These networks may consist of a single network segment, or they may have complex topologies that incorporate many network segments interconnected by other communications links.
The terminals 14, 16, and 18 provide audio and optionally video and data communications capability in point-to-point or multi-point conferences. Interworking with other terminals, such as PSTN endpoints 30 and 32 or ISDN endpoints 34 and 36, is accomplished through gateways like gateway 22 if a PSTN 26 or an ISDN 28, respectively, is involved. Gatekeeper 20 provides admission control and address translation services. Multi-point control unit 24 provides support for multi-point conferences. The scope of H.323 is defined by the dotted lines 38 and does not include the network interface, the physical network, or the transport protocol used on the network. Examples of these networks that could comprise part of PSN 12 include but are not limited to the Ethernet (Institute of Electrical and Electronic Engineers (IEEE) 802.3), Fast Ethernet (IEEE 802.3xcexc), Fiber Distributed Data Interface (FDDI), Token Ring (IEEE 802.5), and Asynchronous Transfer Mode (ATM).
H.323 endpoints, such as terminals 14, 16, or 18, multi-point control unit 24, or gateway 22, may establish media channels in a call using either the procedures defined in ITU-T Recommendation H.245 (H.245) or the Fast Connect procedure described in the H.323 standard although the latter is preferred. The Fast Connect procedure allows the endpoints to establish a basic point-to-point call with as few as one round-trip message exchange, enabling immediate media stream delivery upon call connection. The H.245 requires a set of message exchanges to setup the call. For example, the H.245 requires determining a master-slave exchanging a capability, opening logical channels on both endpoints and acknowledging the logical channels on both endpoints, closing and re-opening the logical channels, and the like. The Fast Connect feature eliminates the need to establish a separate H.245 Transfer Control Protocol (TCP) connection by using the existing H.225 channel for a simplified capability exchange between two endpoints. Another advantage of a Fast Connect call is that the audio, data, and/or video paths, if supported, are available much sooner than would be the case using the H.245 procedures. In essence, Fast Connect uses the resources more efficiently, reduces the overhead of establishing media channel(s) for a call, and establishes the media paths sooner than using the H.245 procedures.
FIG. 2 is a functional block diagram describing a drawback with the communications system 10 shown in FIG. 1. A calling endpoint 40, such as gateway 22 (FIG. 1), initiates a call by sending a message containing certain predetermined elements to a called endpoint 42, such as terminal 18. In H.323, the Fast Connect call procedure is initiated by sending a SETUP message containing a faststart element. The faststart element consists of a sequence of OpenLogicalChannel structures 43 describing a particular media channel proposalxe2x80x94audio, video, or dataxe2x80x94and a certain directionxe2x80x94send or receivexe2x80x94. Where the media channel proposal involves audio, the OpenLogicalChannel structure 43 describes, among other things, media channel capabilities associated with respective audio coder/decodersxe2x80x94commonly known as codecsxe2x80x94that the calling endpoint 40 can use to encode and decode audio signals. In other words, the calling endpoint 40 advertises its send and receive codec capabilities to the called endpoint 42. Here, the send directionxe2x80x94the term xe2x80x9cforwardxe2x80x9d is used in the H.323 standardxe2x80x94refers to signals traveling from the calling endpoint 40 to the called endpoint 42. Conversely, the receive directionxe2x80x94xe2x80x9creversexe2x80x9d in the H.323 standardxe2x80x94refers to signals traveling from the called endpoint 42 to the calling endpoint 40.
For example, the calling endpoint 40 sends notification 43 to the called endpoint 42 that it has audio codec 1, codec 2, . . . , codec N (44) available for encoding signals to packets (send direction) and audio codec 1, codec 2, . . . , codec M (46) available for decoding the packets back into audio or video signals (receive direction). In the H.323, the plurality of codec options is included in the OpenLogicalChannel structure 43 sent in the call setup message. The codec options are, for example, audio G.729, G.711, G.723, G.726, and the like.
The called endpoint 42 chooses one of the codec capabilities 44 proposed by the calling endpoint 40 for the send direction and one codec 46 for the receive direction. For example, endpoint 42 selects codec 2 for encoding packets in the send direction 48 and selects codec 1 for decoding packets in the receive direction 50. The choice of which codec the called endpoint 42 will choose depends on several factors including which codecs the called endpoint 42 supports and is configured to use. More specifically, the choice of codecs depends on the codecs supported by digital signal processing software or firmware included in the called endpoint 42.
Often, the calling endpoint 40 does not support using different codecs for the send and receive directions (asymmetric). In such a case, if the called endpoint 42 selects one codec for the send direction and a different codec for the receive direction, the calling endpoint 40 will be unable to proceed with the fast call. If the calling endpoint 40 wishes to maintain a speech path, for example, with the called endpoint 42, the calling endpoint 40 must revert from the Fast Connect call to a normal call by establishing a separate, slower, H.245 TCP connection. The called endpoint 42 may also refuse the Fast Connect call by not returning the faststart element in any return message up to and including the CONNECT message. When the Fast Connect call cannot be initiated, the H.245 procedure is used for capabilities exchange and opening of media channels. It is possible for the called endpoint 42 to select the same codecs for the send and receive direction thereby successfully establishing a fast callxe2x80x94e.g., a H.323 Fast Connect callxe2x80x94with the calling endpoint 40. However, it is not guaranteed under current protocol specifications.
It is important to emphasize that the H.245 TCP call procedures require much more overhead to establish calls than the H.323 procedures. An H.245 call also uses resources less efficiently and is slower. Thus, is it beneficial to establish calls using the Fast Connect procedures whenever possible.
A workaround for the above-described drawback is shown in FIG. 3. Assume again that the calling endpoint 40 does not support different or asymmetric codecs for the send and receive directions. The calling endpoint 40 provides the called endpoint 42 a single choice of codec 52 for the send and receive direction, for example, codec 2. Because the called endpoint 42 is only given the one choice of codec 2 for both send and receive directions, endpoint 42 is precluded from choosing asymmetric codecs. However, if the called endpoint 42 does not support the one codecxe2x80x94codec 2xe2x80x94proposed by the calling endpoint 40, the call is rejected, requiring invocation of the H.245 call setup procedures.
Accordingly, a need remains for a communications system affording a calling endpoint the ability to offer a called endpoint more than a single choice of codecs for encoding and decoding data in the send and receive directions while at the same time alerting the called endpoint when only symmetric codecs must be selected for encoding and decoding data.
The object of the invention is a communications system that increases successful fast call setups, improves resource utilization, and reduces overhead. The communications system of the present invention includes a calling endpoint coupled to a called endpoint through a packet switched network. A flag is encoded in a fast call setup message sent from the calling endpoint to the called endpoint through the packet switched network. The flag indicates to the called endpoint whether the calling endpoint wishes for the called endpoint to select asymmetric channel capabilities for encoding and decoding audio and video signals in the send and receive directions. The flag allows the calling endpoint to present the called endpoint with a plurality of different codec options for the send and receive directions. The called endpoint can then choose which one of the codec options is best suited for the proposed call based on the wishes of the calling endpoint.
If the calling endpoint does not support asymmetric channel capabilities, the flag indicates to the called endpoint that the calling endpoint wishes it choose the same or symmetric capability from the plurality of codec options presented for both the send and receive directions. If the calling endpoint supports asymmetric channel capabilities, the flag indicates to the called endpoint that the calling endpoint believes it is unrestricted in its choice of which codecs to select for encoding and decoding data. That is, the called endpoint can choose one codec for encoding data in the send direction and select the same or a different codec for decoding encoded data in the receive direction.
By establishing the call in this manner, a calling endpoint that does not support asymmetric codec capabilities is not faced with a failed call because the called endpoint has selected different or asymmetric codecs for the send and receive directions. Thus, more calls are successfully set up avoiding the necessity of defaulting to less efficient call procedures.
A method for improving communications efficiency in a packet based communications system includes sending a call setup message from a calling endpoint to a called endpoint. The calling endpoint sends a call setup message that offers a choice of different codecs for encoding audio, video, and/or data signals into packets in the send direction and another choice of codecs for decoding previously encoded packets in the receive direction. The called endpoint evaluates the flag to determine whether the calling endpoint supports asymmetric capabilities. The called endpoint then chooses a channel capability for the send and receive directions based on the flag. If the calling endpoint has set the flag to indicate symmetric capabilities, the called endpoint must chose the same codec for the send and receive directions. Conversely, if the calling endpoint has not set the flag to enforce the selection of symmetric capabilities, the called endpoint is unrestricted in its choice of codecs. That is, the called endpoint can choose the same codec or different codec for each of the send and receive channels.